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Ch annel reallocation method and device 
[Field of the invention] 

The present invention relates to a method and device for 
reallocating circuit -switched channels that are associated 
with a gateway node that is arranged to establish 
communications between a first communication network and a 
second circuit-switched communication network, where the 
reallocation is performed with respect to at least two 
control entities that are arranged to control communications 
between the two networks, where each of said control entities 
is allocated a respective group of said circuit-switched 
channels associated with the gateway node. 



[Background of the invention] 



In order to provide communications between different 
networks, it is known to employ so-called media-gateways, 
which are devices that convert media input from one network 
into a form suitable for another network. For example, media 
gateways can be provided between a packet -switched network 
(e.g. an IP based network) on the one hand and a circuit- 
switched network (e.g. a PSTN) on the other hand. 

Furthermore, it is known to functionally separate the control 
over the communications between the two networks connected by 
the media .gateway from the media gateway, by providing 
separate control entities, which can also be referred to as 
media gateway controllers. It may noted that the media 
gateway and media gateway controller are functionally 
separated, which means that they can also be physically 
separated, but could also be located in the same network 
node . 
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The division into a media gateway (or media gateway node) and 
a media gateway controller allows an increased flexibility in 
arranging the communication networks, and e.g. enables the 
5 separation of hardware resources from logical software 
resources. This division can also be exemplified by the 
concept of a control plane and a bearer plane, where the 
media gateway is at the bearer plane and the media gateway 
controller is at the control plane. 

10 

A special situation arises if one of the networks connected 
to the media gateway is a circuit-switched network, and the 
communication via the media gateway is handled through a 
predetermined number of circuit-switched channels 

15 specifically associated with the media gateway. In other 
words, communications to and from said circuit -switched 
network over said media gateway are conducted over a 
predetermined number of circuit -switched channels assigned to 
the media gateway. If more than one media gateway controller 

20 is connected to the media gateway under consideration, then 
the circuit-switched channels associated with the media 
gateway are grouped, and respective groups are allocated to 
each media gateway controller, such that each media gateway 
controller can control communications between the two 

25 networks via the circuit-switched channels in the allocated 
group. 

In such a situation there will be a 1-to-l relation between a 
software resource in the media gateway controller, a physical 
3 0 connection to the circuit -switched network in the media 
gateway, and a channel identifier, which is used in the 
control protocol between the media gateway and the media 
gateway controller. 



■1 
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[Object of the invention] 

The object of the invention consists in providing a flexible 
5 and efficient way of allocating and reallocating circuit- 
switched channels among control entities. 

[Summary of the invention] 

10 This object is solved by a method described in claim 1 and a 
device described in claim 13. Advantageous embodiments are 
described in the dependent claims. 

According to the present invention, the allocation and 
15 reallocation of circuit -switched channels among control 

entities is accomplished by automatically monitoring one or 
more sources of communication performance information, 
automatically determining whether a reallocation triggering 
condition is met, on the basis of data received from these 
20 sources, and if said reallocation triggering condition is 
met, automatically performing a reallocation procedure. The 
reallocation procedure calculates a reallocation of the 
circuit-switched channels associated with the gateway node 
under consideration, among the two or more control entities 
25 connected to the gateway node. 

Due to the above described concept of automatically 
monitoring sources of communication performance information, 
and performing a reallocation calculation when predetermined 

30 triggering conditions are met, a reallocation of circuit- 
switched channels among the control entities does not have to 
be performed manually. Especially, the system can dynamically 
determine the optimum channel allocation among the control 
entities, such that the resources are most efficiently used 

35 in view of the momentary communication performance. For 
example, it can be avoided that congestion occurs with 
respect to a group of channels controlled by one control 
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entity, while channels of a second group controlled by a 
second control entity are idle. Namely, in this case the 
system can perform an automatic reallocation calculation, in 
order to determine a better allocation of the circuit - 
switched channels among the control entities. 

[Brief description of figures] 

The present invention will now be described by way of 
preferred embodiments, which are to be seen as examples but 
not as limiting, and by referring to the enclosed drawings in 
which: 

Fig. 1 gives a schematic overview of an embodiment of the 
invention; 

Fig, 2 shows a flow chart of a basic method according to 
the present invention; 

Fig. 3 shows an embodiment of a reallocation procedure 

that can be used in the context of the method shown 
in Fig. 2; and 

Fig. 4 shows a schematic representation of an automatic 
reallocation handler of the present invention. 

[Detailed description] 

Fig. 1 shows a schematic representation of an embodiment of 
the present invention. Reference numeral 1 refers to a first 
communication networJc and reference numeral 2 to a second, 
circuit -switched communication network. A gateway node 3 is 
provided between the networks 1 and 2, for establishing 
communications between the two networks. As indicated 
schematically in the figure, the communication from the 
gateway node 3 to and from the communication network 2 is 
conducted via a set of channels chl...chn (n is a natural 
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number) , which are associated with the gateway ^node 3 . The 
channels chl to chn are defined according to the concept of 
circuit -switching used in network 2 and can e.g. be time 
division multiplex (TDM) channels if network 2 is a TDM-based 
5 network. 

It may be noted that the communication network 1 can be of 
any type, and can especially be packet-switched communication 
network, such as a network based upon the internet protocol 

10 (IP) , whereas the network 2 can be any suitable circuit- 
switched network, such as a public switched telephone network 
(PSTN) , or a mobile telephone network adhering to the global 
system for mobile communication (GSM) . For example, according 
to a preferred embodiment the communication network 1 is a 

15 UMTS (Universal Mobile Telecommunications System) or GPRS 
(General Packet Radio Service) network. 

The channels chl... chn are divided into groups, where each 
group is allocated to one of a plurality of control entities 
2 0 4 and 5. Fig. 1 only shows two control entities 4 and 5 for 

the purpose of clarity, but it should be understood that a 
larger number could be provided as indicated by the dots to 
the right of entity 5. The control entities 4 and 5 can e.g. 
be the media gateway controllers mentioned in the 
25 introduction to the present application. 

In accordance with the present invention, an automatic 
reallocation handler 6 is provided which is arranged to 
automatically monitor one or more sources 31, 41, 51 of 

30 communication performance information, where said 

communication performance information relates to the use of 
the channels chl, chn by the control entities 4 and 5. 

Furthermore, the automatic reallocation handler 6 is arranged 
to automatically determine whether a reallocation triggering 

35 condition is met, where said determination is conducted on 
the basis of the data received from the sources 31, 41, and 
51. If the reallocation triggering condition is met, a 
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reallocation procedure is conducted, for calculating a 

reallocation of the channels chl, chn among the control 
entities 4 and 5. 

5 A basic method performed by the automatic reallocation 
handler 6 is shown in Fig. 2 . In a first step SI, the 
automatic monitoring of the sources 31, 41, 51 is conducted, 
and in step S2 it is determined whether a reallocation 
triggering condition is met or not. If a reallocation 

10 triggering condition is met, then the reallocation procedure. 
S3 is conducted. If the triggering condition is not met, then 
the procedure jumps to a determination step S4, in which it 
is determined whether the procedure should end or not. If it 
is decided to continue the procedure, the steps starting with 

15 step SI are repeated. It should be noted that the automatic 
reallocation handler 6 is a functional entity that can be 
provided in a single physical entity or can be spread out 
over several entities, e.g. can be provided in one node of 
the network 1 (such as the gateway node 3) , or can be spread 

20 out over several nodes. The automatic reallocation handler 6 
can be provided by hardware, software or any suitable 
combination of hardware and software. 

In accordance with the embodiment described in connection 
25 with Figs. 1 and 2, it is possible to dynamically allocate 
and reallocate the channels chl, chn among the control 

entities 4 and 5. For example, if an initial allocation of 
channels to the control entities is assumed to be 
chl, chm (m is a natural number smaller than n) 

30 allocated to control entity 4, and chm+1, chn allocated 

to control entity 5, then the automatic reallocation handler 
6 can be arranged to monitor the use (occupation) of the 
respective channel groups by the respective control entities. 
The automatic determining step S2 can e.g. be arranged such 
3 5 that the triggering condition consists in comparing whether 
the number of momentarily occupied channels in one group 
exceeds a predetermined threshold (e.g. 95%) , and triggers 
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the reallocation procedure S3 when this threshold is 
exceeded. Then the automatic reallocation procedure S3 can 
e.g. determine the momentary occupation of channels in other 
groups, and if there is sufficient number of idle channels, 
5 the reallocation calculation can be performed in order to 
allocate more of the channels chl, chn to the control 

entity for which the threshold was exceeded. 

With respect to the above-mentioned example of groups chl, 
10 chm and chm+1, chn, it would e.g. be possible to 

reallocate channels chm+1, chk (m < k < n) from the 

group allocated to control entity 5 to the group allocated to 
control entity 4, when the automatic determining step S2 
determines that the number of occupied channels in group chl, 
15 . . . , chm exceeds a given threshold, and the reallocation 

procedure S3 determines that there is a sufficient number of 
idle channels in the group chm, . . . , chn allocated to control 
entity 5. 

20 In the above example a source of communication performance 
information was assumed that provides an indication of the 
momentary channel occupation for each of the allocated 
groups. In general, any suitable source of communication 
performance information can be used, as is desirable in 

25 connection with the particular networks, gateway node and 
control entities involved. According to a preferred 
embodiment, the one or more sources of communication 
performance information can be a channel occupation monitor 
for comparing the number of momentarily occupied circuit - 

30 switched channels among the circuit -switched channels 

allocated to a particular control entity with one or more 
predetermined occupation thresholds, and/or a traffic volume 
monitor for comparing a time average of a number of occupied- 
switched channels among the circuit-switched channels 

35 allocated to a particular control entity with one or more 
predetermined traffic thresholds. 
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In the above described example, the channel occupation 
monitor was assumed to compare the percentage of momentarily 
occupied circuit -switched channels with one predetermined 
upper threshold (95% in the example), but such a channel 
5 occupation monitor can also perform a comparison with more 
than one upper threshold, where each threshold is arranged to 
indicate a different occupation situation. As an example, the 
above mentioned threshold of 95% could be a warning 
threshold, that congestion is to be expected, and a second 
10 threshold of 99% or 100% could be a threshold for indicating 
that congestion has occurred. In other words, the exceeding 
of the 99% or 100% threshold can be viewed as a congestion 
alarm, whereas the threshold of 95% can be viewed as a 
service alarm. 

15 

Equally, the channel occupation monitor can also be arranged 
to indicate when the channel occupation falls below a certain 
threshold, e.g. when the occupation falls below 25%, which 
can serve as a warning that resources are being wasted. 

20 

In summary, the channel occupation monitor can be arranged to 
compare the channel occupation of channels allocated to a 
given control entity with one or more upper and/or lower 
thresholds . 

25 

In place of, or in addition to the above described channel 
occupation monitor, which monitors the momentary channel 
occupation, a traffic volume monitor or performance counter 
can be provided for comparing a time average of the 

30 occupation of circuit -switched channels in the respective 

groups allocated to respective control entities. Similar to 
the above described situation of the channel occupation 
monitor, one or more upper thresholds can be defined in order 
to define congestion situations, and/or one or more lower 

3 5 thresholds can be defined, in order to indicate resource 
waste situations. 
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As -indicated in Fig. 1, the sources 31, 41, 51 of 
communication performance information can be provided in 
conjunction with the gateway node 3 and/or the control entity 
4 and/or the control entity 5. Also, it should be noted that 
5 the above -described threshold comparisons can be performed in 
the sources 31, 41, 51, or these sources may only provide 
information, which is compared in the automatic reallocation 
handler 6. 

10 Returning to Figure 2, the reallocation procedure S3 is 

preferably arranged to discriminate between reallocatable and 
non-reallocatable circuit-switched channels from among the 
channels chl, chn, where the calculating of a 

reallocation is only performed for the reallocatable 
15 channels. This serves to prevent certain reserved channels, 
such as signalling channels, from being automatically 
reallocated by the automatic reallocation handler 6. 
According to a preferred embodiment, the automatic 
reallocation handler and underlying control method are 
2 0 arranged in such a way that the classification into 
reallocatable and non-reallocatable channels is user 
controlled, e.g. a user of the automatic reallocation handler 
(e.g. the operator of network 1 and/or 2) can mark certain 
channels among the channels chl, chn as being non- 

25 reallocatable. 

Preferably, the step S2 of automatically determining whether 
a reallocation triggering condition is met comprises checking 
whether data received from one or more of the sources 31, 41, 
30 51 fulfils one or more rules. According to a preferred 
embodiment, these rules are user configurable. 

The rules specify conditions that the data from the sources 
of communication performance information must fulfil in order 
35 to cause a consequence, said consequence also being specified 
by that rule. The one or more rules can thereby specify a 
more or less complicated reallocation triggering condition. 
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For example, a simple reallocation triggering condition can 
be specified by a single rule, according to which if the 
momentary channel occupation of a given group associated with 
a given control entity exceeds a given percentage, then a 
5 reallocation procedure will be triggered. A more complicated 
example would be that if the momentary channel occupation of 
a first given group of channels associated with a first 
control entity exceeds a first threshold (e.g. 95%), and the 
momentary channel occupation of a second given group of 

10 channels associated with a second given control entity falls 
below a second threshold (e.g. 25%), and the average channel 
occupation in the first group exceeds a given first traffic 
threshold (e.g. 85%), and finally the average channel 
occupation in the second group falls below a second traffic 

15 threshold (e.g. 40%), then a reallocation is triggered for 
these two groups. 

As a part of the reallocation procedure S3 shown in Fig. 2, 
it is possible that the automatic reallocation handler also 

20 automatically executes the calculated reallocation. In other 
words, after having performed the reallocation calculation of 
circuit-switched channels among the control entities, 
appropriate signalling is conducted towards the gateway node 
3 and the affected control entities, such that the new 

25 allocation becomes implemented. 

According to a preferred embodiment, the reallocation 
procedure S3 shown in Fig. 2 is conducted in accordance with 
a procedure explained in Fig, 3. The steps S31 to S37 shown 

30 in Fig. 3 constitute an example of the general reallocation 
procedure S3 shown in Fig. 2. According to this preferred 
example, the reallocation procedure S3 comprises a step S31 
of checking whether a condition for automatic reallocation 
execution is fulfilled (i.e. whether automatic execution is 

35 allowed) , and if the condition is fulfilled, executing the 
calculated reallocation in a step S32, as explained above - 
However, if the automatic reallocation execution is not 
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allowed then an indication that a reallocation has been 
calculated, is output to a user, see step S33. 

The checking whether the automatic reallocation execution is 
5 allowed can be done in any suitable or desirable way. For 
example, it is possible that a flag can be set by the user, 
where one flag setting indicates that automatic execution is 
allowed, and the other setting indicates that reallocation 
execution requires user confirmation. However, other 

10 possibilities for checking whether automatic reallocation 
execution is allowed exist, such as checking if a timing 
value is in a predetermined range, or if predetermined 
(external) signal is present or not. For example, it is 
possible that an automatic execution is only allowed if a 

15 timer has expired, where the timer is reset to a given value 
every time that an automatic reallocation execution is 
conducted. In this way it can be avoided that an automatic 
reallocation execution is conducted too often. Also, 
combinations are possible, e.g. that both a flag and a timer 

20 value must fulfil respective conditions. 

The output of a reallocation calculation indication in step 
S3 3 can be done in any suitable or desirable way. For 
example, the automatic reallocation handler 6 can have an 
25 appropriate user interface (such as presentation software and 
a computer screen) , which can communicate a notification to 
the user. 

Subsequent to step S33, step S34 determines whether a user 
30 input has occurred, and if yes, then the subsequent step S35 
determines whether the user has confirmed the reallocation. 

If yes, the procedure branches to step S32 for executing the 
calculated reallocation, and if not, then the procedures 
continues without executing the calculated reallocation. In 
3 5 other words, the reallocation procedure waits for a user 
confirmation input, and if the user confirmation is input, 
the calculated reallocation is executed. 
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If the outcome of step S34 is negative, then the procedure 
branches to step S36, in which it is determined whether the 
reallocation is still needed. If it is, then the procedure 
5 branches back to step S34, in order to wait for a user input. 
If not, then the user confirmation is disabled in step S37, 
and the procedure continues without execution of the 
calculated reallocation. The determination of step S36 is 
conducted on the basis of the momentary data received from 

10 the one or more sources 31, 41, 51 of communication 

performance information, preferably by invoking a step 
identical to step S2 of Fig. 2, in order to determine whether 
the conditions that led to the calculation of the 
reallocation presently under consideration still exist or 

15 not. 

The disabling of the user confirmation is step S37 can be 
conducted in any desirable or suitable way, e.g. by removing 
the notification given in step S33 from the user interface, 
20 or by providing a second, different indication that a 
confirmation is no longer possible, and disabling a 
corresponding input channel from the user interface that 
relates to the first notification given in step S33. 

25 According to another preferred embodiment, each calculated 
reallocation is recorded together with a time-stamp and 
information associated with the reallocation triggering 
condition (e.g. the affected rules that triggered the 
reallocation calculation) . Such a log of events can be very 

30 helpful for a user when analysing the performance of the 
system and the performance of the automatic reallocation 
handler 6. As shall be explained in more detail with respect 
to Fig. 4, the rules for determining whether a reallocation 
triggering condition is met are preferably user adaptable, so 

35 that the recorded reallocation calculations can be used by 
the user to fine-tune the rules. 
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The extent to which the rules are user adaptable can be 
chosen as is useful or desirable. For example^ it is possible 
that the rules are fully user definable, such that a user can 
write rules in an appropriate control language. Alternatively 
5 or additionally it is possible that there are predefined 
rules, in which the user only enters parameter values (e.g. 
thresholds) / such as "if the momentary occupation is above x 
%, then reallocate", where the user must only specify the 
value for x, 

10 

Fig. 4 shows a schematic representation of a preferred 
embodiment of the automatic reallocation handler 6. As 
already mentioned, the automatic reallocation handler 6 can 
be implemented as hardware, software or any suitable 
15 combination of hardware and software, such that the entities 
61-68 to be described in connection with Fig. 4 can equally 
be embodied by hardware, software or any suitable combination 
thereof . 

20 Reference numeral 61 relates to a user interface, reference 
numeral 62 to an event log for recording reallocation 
calculation events, reference numeral 63 relates to a task 
data base, reference numeral 64 to a rule data base, 
reference numeral 65 to a task module, reference numeral 66 

25 to a rules module, and reference numerals 67 and 68 to 

interface adapters for interfacing with control entities such 
as media gateway controllers 4 and 5 of Fig. 1. 

The automatic reallocation handler 6 shown in Fig. 4 is fully 
30 user configurable via the user interface 61. The user 

interface 61 can interact with the task database 63, in order 
to define one or more automatic monitoring tasks with respect 
to the sources of communication performance information. For 
example, a task can indicate which information to acquire 
35 from which node. Furthermore, the user interface interacts 
with the rules database 64, in order to let the user create 
rules. As already described above, a rule specifies one or 
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more conditions that relate to the meeting of a reallocation 
triggering condition. For each rule, it is specified when the 
checking of the rule is triggered (e.g. the receipt of which 
communication performance information triggers a checking of 
5 the rule), and which result the rule will trigger, e.g. the 
consequence of the rule. These consequences of the rules can 
also be defined as tasks in the task database 63, such that 
the user interface 61 can also interact with the task 
database 63, in order to define configuration actions to be 
10 undertaken within such a task. 

The task module 65 is arranged to interact with the task 
database 63, in order to fetch task details and then execute 
such task details on affected nodes via the appropriate node 

15 interface adapter 67, 68. It may be noted that customarily 

one node interface adapter will exist for each gateway node 3 
and each control entity 4, 5. The node interface adapter 
converts the interface format towards the node to/ from the 
format used in the automatic reallocation handler 6. For 

20 example, in a multi-vendor network, one node may implement a 
SNMP (Simple Network Management Protocol) interface, while 
another may implement a CORBA (Common Object Request Broker 
Architecture) interface, or a propriety interface. By 
providing the node interface adapters, the automatic 

25 reallocation handler can communicate with any node. 

The rules module 66 responds to information received from one 
or more of the nodes (both gateway nodes and control 
entities) via the appropriate interface adapter 67, 68. 

30 Namely the rules module receives the communication 

performance information (e.g. an alarm, such as a congestion 
alarm, or simply traffic or channel occupation information, 
which is then processed further in the automatic reallocation 
handler 6) . In response to receiving such communication 

35 performance information, the rules module 66 fetches one or 
more rules associated with the received information from the 
rules database 64, and checks the rules to see if this leads 
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to any task execution as a consequence. If the consequence is 
a task execution (which means that a reallocation procedure 
is triggered) , then a request is sent to the task module 65, 
such that the given task may be performed. Also, it is 
5 possible that the rules module 66 interacts with the event 
log 62, in order to record the occurrence of receiving 
communication performance information, performing a rule 
check and identifying the requested task if a task is . 
requested. 

10 

If a task is requested, the task module 65 checks whether the 
action can be performed automatically (see step S31 and 
subsequent steps in Fig. 3), and if so, fetches details of 
the given task from the task database. Then the task module 
15 65 contacts the affected nodes and implements the calculated 
reallocation via the appropriate node interface adapters 67, 
68. Preferably, details of the reconfiguration are in any 
case (i.e. regardless of whether a reconfiguration was 
executed or not) logged in the event log 62. 

20 

If the task module 65 determines that the task cannot be 
performed automatically, then the appropriate indication 
(also see step S33 Fig. 3) can be output to the user via the 
user interface 61. Preferably, after a reconfiguration has 
25 been executed, an appropriate notification is also given to 
the user via the user interface 61. 

As already mentioned, the automatic reallocation handler 6 
can also be implemented as software. Consequently, the 

30 present invention can also be embodied in the form of a 
computer program arranged to execute one of the above - 
described methods when loaded into and executed on a data 
processing device connected to one or both a gateway node and 
said control entities. Furthermore, the present invention can 

35 also be embodied as a data storage device storing such a 
computer program. 
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As already mentioned initially, the above description of 
detailed examples and embodiments is only intended to provide 
the skilled person with a better understanding of the 
invention, and is not intended to be limiting or restricting. 
5 For example, although Fig. 1 only shows two networks, the 
present invention can also be used in connection with a 
larger number of networks. Equally, although Fig. 1 only 
shows one gateway node 3, the automatic reallocation handler 
6 can be arranged to interact with an arbitrary number of 
10 gateway nodes 3 and any suitable or desirable number of 
control entities 4, 5. 



Further equivalent arrangements will occur to the skilled 
person, which are all intended to fall into the scope of the 
15 invention defined by the appended claims. Reference numerals 
in the claims are intended to make the claims easier to read, 
and are not to be understood as limiting. 



